The SIP protocol has become the protocol of reference for initiating voice communications sessions between several users in an internet protocol (IP) environment. Its aim, optionally within the framework of global network architectures such as those defined by particular standards for allowing a telecommunications operator to offer its clients voice services over an IP network (for example architectures defined by ETSI TISPAN or CableLabs), is to allow uses currently known in commutated telephone networks (CTN) to be reproduced and extended. Users of a SIP network are identified either by a fixed-length telephone number, such as for example ten digits in France, referred to as a closed plan, or variable length such as for example according to geographical area in Germany, referred to as an open plan, or by a dedicated alphanumeric identifier close to the SIP mail format: URI (Uniform Resource Identifier).
The SIP protocol also enables connection to networks of telecommunications operators having different types of users and different types of terminal equipment. Among these, the case of company networks or IP private branch exchange (IPBX) can be mentioned, i.e. private company networks connected over IP to the network of a public operator and capable of offering services to terminals connected on the company network (such as for example speed dialling, etc.) as is currently the case with private automatic branch exchanges (PABX) in companies.
In telephone networks, these entities are generally constituted by one or more number ranges of the numbering plan of the country where they are connected (for example, the range 123456 of the French numbering plan), these ranges themselves capable of being fixed-length, as is the case in France, or variable-length as is the case in other countries.
In the latter case, it is the manager of the company network or IPBX which is responsible for organizing its range(s) into sub-ranges having optionally different lengths.
The network is then transparent to this organization and confines itself to delivering any call directed to one of the numbers of one of its ranges to this company network or IPBX, regardless of the length of this number and whether or not it complies with the number length of the sub-range to which it belongs.
The SIP protocol is based on a concept of double identification of users:                a first identifier, which will hereinafter be called public identity (known as Address of Record), representing the identity on the basis of which the user can be contacted (for example the telephone number or an alphanumeric sequence of the type forename.surname@domain),        a second identifier, which will hereinafter be called the address of contact (known as Contact Address), representing the physical network address where the user can be contacted (for example the IP address of the user terminal).        
The association between a public identity and one (or more) contact address(es) can change over time. A phase called the registration phase allows a user to inform the network and more particularly a specific entity of the latter, which manages his registration status (called the “REGISTRAR”), of the association between his public identity and his contact address(es).
This association is then stored in a location database of a location server associated with the network which will be queried during an incoming request directed to the user (identified by his public identity) in order to find the associated contact address(es) to which this request is to be forwarded.
The implementation of this registration mechanism by the SIP protocol is as follows:
A user agent (“UA”) registers on the network by sending a “REGISTER” message to its “REGISTRAR”. The “To” header of this “REGISTER” message contains the public identity to be registered and the “Contact” header contains its contact address, i.e. the physical address of the corresponding equipment (for example its IP address). On receipt of this “REGISTER” message, the “REGISTRAR” records this information in the location database then responds by an acceptance message (“200 OK”). This message terminates the SIP registration phase.
During a single SIP registration (“REGISTER”—“200 OK”), it is possible to register several contact addresses associated with the same public identity. On the other hand it is not possible to register explicitly, via the SIP signalling, several public entities associated with the same contact address.
Registering several public entities therefore supposes initiating at least as many registrations as the number of public identities to be registered.
In the case for example of an IPBX connected to a public network by means of the SIP protocol and serving several users each allocated a separate public entity, this IPBX must therefore send the same number of REGISTER” messages as the number of public identities required to be accessible from the public network.
The IP multimedia subsystem (IMS) architecture defined by 3GPP and ETSI TISPAN improves this mechanism by allowing the registration, under certain conditions, of several public identities at a single contact address by means of a single SIP registration phase. In fact, this architecture is supported by a user database (called HSS: home subscriber server) in which is stored the set of public identities to which each user subscribes. Now, among a user's public identities, one or more identity sets registered by default can be defined, i.e. one or more identity sets which will automatically be registered by the SIP network when one of the identities of the set is explicitly registered by the user during a SIP registration. The default registration of this identity set associated with the identity during registration is therefore at the initiative of the network, the subscriber being unable to act other than by modifying his subscription offer with his operator.
The characteristic common to the registration mechanism as well as to its enhancement as defined within the IMS architecture framework is the individual and exhaustive storage of the public identities registered in the location database.
Following the base mechanisms defined in the SIP protocol, a “UA” desiring to register several public identities simultaneously must currently initiate as many registrations as the number of entities to be registered. This has the drawback of leading to a heavy network load in terms of messages exchanged and associated processing, and consequently may give rise to instances of congestion.
The registration moreover generally takes place at initialization (or reinitialization) of a “UA” and must periodically be refreshed. However, as such reinitialization can occur after a network problem, sending a significant number of messages following a network problem can then itself aggravate this network problem.
Finally, this results in a registration delay for all users, which can be also problematic given that an unregistered user can neither receive nor transmit calls.
The mechanism supported by the IMS architecture for defining default-registered identities overcomes these drawbacks, since a single “REGISTER” message is sufficient to register several public identities. On the other hand, it requires prior declaration in the network of each of the identities which are to be the subject of a group registration, as well as the storage of these identities in the location database.
This is not at all suited for example to an IPBX or a company network allocated open telephone number ranges, as this requires the internal organization of the number range to be made visible by the public network and furthermore requires a needlessly large storage volume of the individual numbers of the range.
This moreover involves a complex process for synchronizing the public network data with the modifications (addition, deletion of numbers, etc.) that can be made at any time by the company network or IPBX manager to the organization of its number range(s).
The same drawbacks are observed when the company network users are in sip form: URI (ex. sip: terminal X@YYYYYY.com with X varying from 0 to 100). It is noted that such a company desiring to increase the number of its terminals must contact its connecting operator in order to modify its default registration parameters.
The commuted telephone network (CTN) allows the numbering to be transmitted as the number is dialled by the subscriber in the form of a succession of messages each containing a partial sequence of the number dialled. This “overlap” mechanism is often used when the number dialled belongs to an open plan (i.e. to a range of variable length). In the framework of an IMS-type architecture, an incoming call request carrying a partial number sequence is rejected by the network in the same way as if this sequence corresponded to a non-allocated (i.e. unregistered) number. This is linked to the fact that only a complete number can be registered on a SIP network and requires the presence of an intermediate network upstream of the SIP network which detects an overlap numbering and reconstitutes the numbering from the partial sequences received before submitting the message to the SIP network.